JCL - Dotaz na pouziti ExceptionDialog
Otázka od: boh.svancara@quick.cz
15. 10. 2002 16:47
Dotaz asi na Petra Vonese...
Chtel bych se ujistit, jestli je nasledujici
pouziti ExceptionDialog vporadku a ze neni nekde
neco jeste potreba nastavit. (Zda se, ze to
funguje, ale pro jistotu.)
Duvod teto konstrukce je ten, ze napriklad
vyjimka z TField.OnValidate se neda nikde v try-
except odchytit a bezne hlaseni pro uziovatele,
ze blbe vyplnil udaj, vypada v ExceptionDialog
jako vazna chyba v programu.)
procedure THlavniOkno.AppOnException(Sender:
TObject; E: Exception);
begin
if (E is EAccessViolation)
or (E is EAssertionFailed)
or (E is EConvertError)
or (E is EDivByZero)
or (E is EExternal)
or (E is EExternalException)
or (E is EHeapException)
or (E is EInOutError)
or (E is EIntError)
or (E is EIntOverflow)
or (E is EIntfCastError)
or (E is EInvalidCast)
or (E is EInvalidOp)
or (E is EInvalidOperation)
or (E is EInvalidPointer)
or (E is EMathError)
or (E is EOutOfMemory)
or (E is EOverflow)
or (E is EPackageError)
or (E is EPrivilege)
or (E is EPropReadOnly)
or (E is EPropWriteOnly)
or (E is ERangeError)
or (E is EStackOverflow)
or (E is EUnderflow)
or (E is EVariantError)
or (E is EWin32Error)
or (E is EZeroDivide)
then ExceptionDialogClass.ShowException(E,nil)
else Application.ShowException(E);
end;
S pozdravem
Bohuslav vancara, prom. mat.
svancara@softprojekt.cz
Odpovedá: Petr Vones
15. 10. 2002 15:22
From: <boh.svancara@quick.cz>
> Chtel bych se ujistit, jestli je nasledujici pouziti ExceptionDialog
> vporadku
> Duvod teto konstrukce je ten, ze napriklad vyjimka z TField.OnValidate se
> neda nikde v try-except odchytit a bezne hlaseni pro uziovatele,
Predevsim bych tu podminku otocil, takze bych rozhodoval podle te vyjimky
ktera se vyvola z TField.OnValidate a ne vyjmenovavat ruzne vyjimky, protoze
tak je to nelogicke. Muze prece existovat nekonecne mnozstvi ruznych trid
vyjimek, ktere mohou v aplikaci vzniknout, zatimco ta mnozina ktera muze
vzniknout v udalosti TField.OnValidate je znama.
Mozna by se tam dal pridat nejaky filtr na potlaceni zobrazeni toho dialogu
pro nektere typy vyjimek. Tim ze to neni (dost dobre nemuze byt) komponenta je
s tim pak ale trochu vice prace. Zvazuji take moznost ten dialog prepsat tak,
aby pouzival jen Win32 API protoze pri pripadnem padu aplikace nemusi VCL jiz
vubec fungovat.
Petr Vones
Odpovedá: boh.svancara@quick.cz
15. 10. 2002 17:16
Diky za odpoved Petre.
V uvedene podmince je seznam vsech "tezkych"
havarii programu okopirovany z helpu Delphi. Pro
tyto tezke havarie chci volat ExceptionDialog.
Pro nekonecne mnozstvi dalsich vyjimek, ktere
programator neodchytil se vola normalni
Application.ShowException.
Jeste jednou puvodni otazka: Neni potreba jeste
nekde nejaka inicializace toho ExceptionDialogu?
S pozdravem
Bohuslav Svancara, prom. mat.
svancara@softprojekt.cz
-----Original Message-----
From: delphi-l-owner@clexpert.cz [mailto:delphi-l-
owner@clexpert.cz]On
Behalf Of Petr Vones
Sent: Tuesday, October 15, 2002 4:23 PM
To: delphi-l@clexpert.cz
Subject: Re: JCL - Dotaz na pouziti
ExceptionDialog
From: <boh.svancara@quick.cz>
> Chtel bych se ujistit, jestli je nasledujici
pouziti ExceptionDialog
> vporadku
> Duvod teto konstrukce je ten, ze napriklad
vyjimka z TField.OnValidate se
> neda nikde v try-except odchytit a bezne
hlaseni pro uziovatele,
Predevsim bych tu podminku otocil, takze bych
rozhodoval podle te vyjimky
ktera se vyvola z TField.OnValidate a ne
vyjmenovavat ruzne vyjimky, protoze
tak je to nelogicke. Muze prece existovat
nekonecne mnozstvi ruznych trid
vyjimek, ktere mohou v aplikaci vzniknout,
zatimco ta mnozina ktera muze
vzniknout v udalosti TField.OnValidate je znama.
Mozna by se tam dal pridat nejaky filtr na
potlaceni zobrazeni toho dialogu
pro nektere typy vyjimek. Tim ze to neni (dost
dobre nemuze byt) komponenta je
s tim pak ale trochu vice prace. Zvazuji take
moznost ten dialog prepsat tak,
aby pouzival jen Win32 API protoze pri pripadnem
padu aplikace nemusi VCL jiz
vubec fungovat.
Petr Vones
Odpovedá: Petr Vones
15. 10. 2002 17:58
From: <boh.svancara@quick.cz>
> V uvedene podmince je seznam vsech "tezkych"
> havarii programu okopirovany z helpu Delphi. Pro
> tyto tezke havarie chci volat ExceptionDialog.
> Pro nekonecne mnozstvi dalsich vyjimek, ktere
> programator neodchytil se vola normalni
> Application.ShowException.
To je velmi zvlastni zpusob osetrovani chyb v aplikaci. V zasade kazda vyjimka
ktera se dostala az k TApplication.OnException je zavazna. V pripade toho
TField.OnValidate bych volil cestu zobrazeni dialogu pri chybne hodnote a
nasledne volani SysUtils.Abort ktere vyvola specialni vyjimku, jenz je sice
odchycena na urovni TApplication, ale nevola zadnou dalsi udalost ani
nezobrazuje dialog.
> Jeste jednou puvodni otazka: Neni potreba jeste
> nekde nejaka inicializace toho ExceptionDialogu?
Ten dialog se inicializuje sam. Pokud v nem chces delat podobne upravy jake
jsi uz predtim naznacil, tak je asi nejlepsi z Repository udelat Copy a pak
jej v te aplikaci doupravit jako kazdy jiny formular. Ohledne implementace
bych asi pouzil TClassList a do neho dal vsechny ty tridy vyjimek.
Petr Vones
Odpovedá: boh.svancara@quick.cz
16. 10. 2002 10:46
Dekuji za odpoved, Petre.
> > Pro nekonecne mnozstvi dalsich vyjimek, ktere
> > programator neodchytil se vola normalni
> > Application.ShowException.
>
> To je velmi zvlastni zpusob osetrovani chyb v
aplikaci. V zasade
> kazda vyjimka
> ktera se dostala az k TApplication.OnException
je zavazna. V pripade toho
> TField.OnValidate bych volil cestu zobrazeni
dialogu pri chybne hodnote a
> nasledne volani SysUtils.Abort ktere vyvola
specialni vyjimku,
> jenz je sice
> odchycena na urovni TApplication, ale nevola
zadnou dalsi udalost ani
> nezobrazuje dialog.
Myslim, ze tento "zvlastni" zpusob je zcela v
intencich programovani v Delphi. Pamatuji si, ze
defaultni osetreni vyjimek bylo dokonce v prvnich
verzich Delphi v reklamnich materialech
vyzdvihovano jako prednost.
Neni pravda, ze kazda vyjimka, ktera se dostala
do TApplication.OnException je zavazna. Prikladem
budiz prave TField.OnValidate. Pokud je udaj
chybny, neda se z OnValidate odejit jinak, nez
pomoci vyjimky. Tato vyjimka se neda nikde
odchytit, takze pokracuje az do
TApplication.OnException. A ma-li se jen oznamit
chyba uzivateli, tak je na to Delphi primo
zarizene. V OnValidate se da tedy jednoduse
udelat raise Exception('Mas tam chybu') a hotovo.
Zadne dalsi kodovani => prehlednejsi program =>
mene chyb. Vysledek je v kazdem pripade stejny -
zobrazeni dialogu s hlaskou a tlacitkem OK.
> Ohledne implementace
> bych asi pouzil TClassList a do neho dal
vsechny ty tridy vyjimek.
Muzu se zeptat proc? Jakou vyhodu tim v tomto
konkretnim pripade ziskam? Prehlednejsi, kratsi
nebo rychlejsi kod? Moznost, ze udelam mene chyb?
Rychlejsi odladeni programu? Lepsi moznosti
dalsiho vyvoje?
S pozdravem
Bohuslav Svancara, prom. mat.
svancara@softprojekt.cz
Odpovedá: Ondrej Kelle
16. 10. 2002 12:18
Ahoj,
[snip]
> Neni pravda, ze kazda vyjimka, ktera se dostala
> do TApplication.OnException je zavazna.
Nemusi to byt pravda, ale vo vseobecnosti je asi uzitocne pisat programy
tak, aby to pravda bola 
> Prikladem budiz prave TField.OnValidate. Pokud
> je udaj chybny, neda se z OnValidate odejit
> jinak, nez pomoci vyjimky. Tato vyjimka se neda
> nikde odchytit, takze pokracuje az do
> TApplication.OnException. A ma-li se jen oznamit
> chyba uzivateli, tak je na to Delphi primo
> zarizene. V OnValidate se da tedy jednoduse
> udelat raise Exception('Mas tam chybu') a hotovo.
> Zadne dalsi kodovani => prehlednejsi program =>
> mene chyb. Vysledek je v kazdem pripade stejny -
> zobrazeni dialogu s hlaskou a tlacitkem OK.
Nemusi byt; mozes zavolat proceduru Abort, ktora vyvola "tichu" exception
EAbort - nezobrazi sa ziadny dialog.
TOndrej
Odpovedá: Petr Vones
16. 10. 2002 14:35
From: <boh.svancara@quick.cz>
> Neni pravda, ze kazda vyjimka, ktera se dostala
> do TApplication.OnException je zavazna. Prikladem
> budiz prave TField.OnValidate. Pokud je udaj
> chybny, neda se z OnValidate odejit jinak, nez
> pomoci vyjimky. Tato vyjimka se neda nikde
Zpusob jakym je reseno TField.OnValidate je zrovna jeden z dobrych prikladu
spatneho designu ve VCL. Spravne by ta udalost mela obsahovat jeste dalsi
promennou typu Boolean, ktera by vracela vysledek validace a dale by TField
mel nejakou dalsi vlastnost (napriklad ValidateErrorMessage) do ktere by se
vlozilo pripadne chybove hlaseni. Reseni, kdy vyvolam "nejakou" vyjimku je
zcela nesystematicke. Jako jina prijatelna moznost by mohla byt i metoda tridy
TField, ktera by vyvolala predem definovanou vyjimku (viz dale) s jasne danym
ucelem a zpusobem obsluhy.
> odchytit, takze pokracuje az do
> TApplication.OnException. A ma-li se jen oznamit
Prave proto existuje vyjimka EAbort.
> chyba uzivateli, tak je na to Delphi primo
> zarizene. V OnValidate se da tedy jednoduse
Toto by bylo jeste prijatelne, pokud by existovala treba vyjimka EUserMessage
odvozena od EAbort, ktera by misto dialogu zobrazujici neosetrenou vyjimku
zobrazila pouze chybove hlaseni. Takto by bylo jednoznacne jasne z jakeho
duvodu ta vyjimka vznikla a jak presne se v tomto specifickem pripade ma
osetrit.
> udelat raise Exception('Mas tam chybu') a hotovo.
> Zadne dalsi kodovani => prehlednejsi program =>
> mene chyb. Vysledek je v kazdem pripade stejny -
> zobrazeni dialogu s hlaskou a tlacitkem OK.
Ze to zrovna v praxi nejak funguje je zcela nepodstatne, z hlediska navrhu je
to spatne reseni, tecka. Co presne rika trida vyjimky Exception ? Co kdyz v
jine casti aplikace bude zrovna take nekde (chybne) pouzita ? Vsechno tohle
vede jen k neprehlednemu a tezko udrzovatelnemu kodu.
> Muzu se zeptat proc? Jakou vyhodu tim v tomto konkretnim pripade ziskam?
> Prehlednejsi, kratsi nebo rychlejsi kod?
Toto reseni je podle mne prehlednejsi nez mit 50 radku kde se opakuje temer ta
sama sekvence. Navic tak lze ty tridy pak i za behu dynamicky registrovat.
Petr Vones
Odpovedá: boh.svancara@quick.cz
16. 10. 2002 16:27
Petre,
>Zpusob jakym je reseno TField.OnValidate je
zrovna jeden z >dobrych prikladu spatneho designu
ve VCL.
s tim ne moc povedenym naprogramovanim
TField.OnValidate (a s dalsim Tvym povidanim o
vyjimkach) nelze nez souhlasit, ale Borlandi
TField.OnValidate takto naprogramovali a ja to
tak musim pouzivat.
>...
>Toto reseni je podle mne prehlednejsi nez mit 50
radku kde se >opakuje temer ta sama sekvence.
No, proto jsem se ptal, jestli ziskam kratsi kod,
protoze
misto padesati radku:
...
or (E is Exyz)
...
budu mit jinych padesat radku:
with TClassList do begin
...
Add(Exyz);
...
end;
+ dalsi rezie, coz mi jako velka vyhra nepripada.
Ale to je nazor proti nazoru a nemusime to uz dal
rozpitvavat.
Petre, co je to za udaj
TJclPeBorForm.FormPosition?
Zdravi Svancara
Odpovedá: Petr Vones
16. 10. 2002 17:51
From: <boh.svancara@quick.cz>
> s tim ne moc povedenym naprogramovanim
> TField.OnValidate (a s dalsim Tvym povidanim o
> vyjimkach) nelze nez souhlasit, ale Borlandi
> TField.OnValidate takto naprogramovali a ja to
> tak musim pouzivat.
Ne tak docela. Muzes si napriklad definovat tu tridu vyjimky pro zobrazeni
hlaseni, filtrovat ji (jako jedinou) v TApplication.OnException a pouzit v
OnValidate.
> + dalsi rezie, coz mi jako velka vyhra nepripada.
Zakladni problem je totiz v tom neco takoveho vubec nedelat, at je to pak
implementovano jakkoli 
Je pravda, ze v Delphi 7 muze mit kod s pouzitim operatoru IS o nekolik bytu
mene, protoze pokud se na nejakou tridu odkazujes pouze operatorem IS, tak se
potom jeji kod nelinkuje do aplikace. To je takova drobna nova optimalizace v
Delphi 7.
Petr Vones
Odpovedá: boh.svancara@quick.cz
16. 10. 2002 22:17
> Ne tak docela. Muzes si napriklad definovat tu
tridu vyjimky pro zobrazeni
> hlaseni, filtrovat ji (jako jedinou) v
TApplication.OnException a pouzit v
> OnValidate.
Petre,
to je sice mozna teoreticky pekne, ale prakticky
je to na nic. Skoncis ne u padesati radku na
filtrovani vyjimek (ve skutecnosti je jich 28),
ale u treba u nekolika stovek. Pricemz napr. ty
deklarovane vyjimky v OnValidate jsou jen na toto
jedno konkretni pouziti a na nic jineho. Jen
proto, aby se odchytily v
TApplication.OnException a zobrazil se ten text,
ktery si s sebou nesou z konstruktoru.
Ve skutecnosti jsem tuto teorii zacal skutecne
realizovat, nez jsem zjistil, ze je to na nic.
Bylo to tak, ze nez jsem pouzil ExceptionDialog,
vsechno fungovalo tak, jak se ocekavalo: uzivatel
zadal do pole chybnou hodnotu, OnValidate vyhodil
vyjimku a Application zobrazila dialog, ze to ma
opravit. Ten mechanismus v Delphi je. A funguje.
I kdyz mozna,
"ze to zrovna v praxi nejak funguje
je zcela nepodstatne, z hlediska navrhu je to
spatne reseni".
Jenze cekat na Delphi nebo
jakykoli jiny program, ktery bude dokonaly "z
hlediska navrhu", bohuzel
nemuzu, protoze se 1000
let asi nedoziju.
Pak jsem aplikoval ExceptionDialog. A misto
jednoducheho hlaseni dostal slozity dialog, ktery
umoznuje krasne veci, jako ukoncit okamzite
program, poslat log e-mailem a podobne
vymozenosti. A navic dlouho trvalo nez se
vygeneroval log.
Takze jako dalsi krok bylo nutno deklarovat
specialni vyjimky a odchytavat je v
TApplication.OnException.
Kdyz jsem delal asi patnactou a porad to bylo to
same (deklarace, raise, odchyceni) tak me to
prestalo bavit a udelal jsem to obracene: odchyti
se jen ty vyjimky, ktere signalizuji opravdu
vaznou chybu v programu a jen tyto vyvolaji
ExceptionDialog s moznosti poslat log
programatorovi. Jejich seznam je znamy a pocet
omezeny na rozdil od nekonecneho mnozstvi
vyjimek, ktere si mohu nadeklarovat, ale pak je
taky musim osetrovat a napriklad i zdokumentovat.
Jak je to u programatoru s dokumentaci je myslim
jasne. A az po mne nekdo prijde, bude muset tu
zbytecnou dokumentaci taky cist. A proc? Aby
zjistil, ze je zbytecna? Aby u kazde
nadeklarovane vyjimky musel zjistovat, kde vsude
je pouzita? Myslim, ze v tomto pripade plati
porekadlo, ze mene je nekdy vice.
S pozdravem
Bohuslav Svancara, prom. mat.
svancara@softprojekt.cz
Odpovedá: Petr Vones
17. 10. 2002 0:28
From: <boh.svancara@quick.cz>
> Ve skutecnosti jsem tuto teorii zacal skutecne
> realizovat, nez jsem zjistil, ze je to na nic.
Teorie neni nanic, pokud se aplikuje vcas.
> spatne
reseni". Jenze cekat na Delphi nebo
> jakykoli jiny program, ktery bude dokonaly "z
> hlediska navrhu", bohuzel nemuzu, protoze se 1000
> let asi nedoziju.
To neni otazka cekani ale pristupu. Vetsinu kodu vytvaris sam a podle toho to
take vypada. Ze je vetsina aplikaci 'zprasenych' ? Mozna, ale to neni muj
problem, driv nebo pozdeji na to vyrobce prijde a zacne mit treba potize.
Specialne u nas je zvykem, ze si malokdo necha poradit (nejake konzultace nebo
snad skoleni jsou povazovany za naprosto zbytecnou investici) a podle toho to
pak v okamziku, kdy se to dostane do neudrzovatelneho stavu vypada. Zatim
jsem, vedom si tohoto pravidla, spolupracoval pouze na nekolika projektech
ktere meli hlavu a patu a byly zvlast zajimave. Velmi nerad to rikam, ale je
to realita.
> Kdyz jsem delal asi patnactou a porad to bylo to
> same (deklarace, raise, odchyceni) tak me to
> prestalo bavit a udelal jsem to obracene: odchyti
> se jen ty vyjimky, ktere signalizuji opravdu
> vaznou chybu v programu a jen tyto vyvolaji
> ExceptionDialog s moznosti poslat log
> programatorovi. Jejich seznam je znamy a pocet
> omezeny na rozdil od nekonecneho mnozstvi
> vyjimek, ktere si mohu nadeklarovat, ale pak je
> taky musim osetrovat a napriklad i zdokumentovat.
Znovu. Kazda vyjimka ktera se dostane az k Application.OnException je zavazna,
krome te, ktere jsme uz probrali. Chapu ze menit design neceho, co je asi od
zakladu spatne je obrovsky narocne, ale jinak to asi nejde.
> Jak je to u programatoru s dokumentaci je myslim
> jasne. A az po mne nekdo prijde, bude muset tu
> zbytecnou dokumentaci taky cist. A proc? Aby
Zbytecnou dokumentaci ? Predstav si, ze pracujes na projektu, kde budes
dokumentovat kazdou tridu, jeji metodu a vazbu na ostatni casti projektu. Ze
to neni zbytecne poznas. Nekdy hned, nekdy pozdeji. Clovek se stale uci a
zkusenost je v mnoha pripadech neprenosna.
> zjistil, ze je zbytecna? Aby u kazde
> nadeklarovane vyjimky musel zjistovat, kde vsude
> je pouzita? Myslim, ze v tomto pripade plati
> porekadlo, ze mene je nekdy vice.
Souhlasim. Mene neporadku je nekdy vice. Pokud se jedna o spojitost s
uzivatelskymi vyjimkami, jako napriklad ta vyvolana z TField.OnValidate pak
nevidim duvod proc jich mit desitky. Opet, je dobre se podivat na vec s
urcitym odstupem (k tomu muze napomoci i nekdo, kdo neni prilis svazan s danou
aplikaci a designem a je schopen do projektu prinest neco noveho nebo zcela
jiny pohled na jeho reseni) a pak vynaset soudy o smysluplnosti.
Petr Vones
Odpovedá: boh.svancara@quick.cz
17. 10. 2002 15:30
> Teorie neni nanic, pokud se aplikuje vcas.
>...
> take vypada. Ze je vetsina
aplikaci 'zprasenych' ? Mozna, ale to neni muj
> problem, driv nebo pozdeji na to vyrobce prijde
a zacne mit treba potize.
> Specialne u nas je zvykem, ze si malokdo necha
poradit (nejake
> konzultace nebo
> snad skoleni jsou povazovany za naprosto
zbytecnou investici) a
> podle toho to
> pak v okamziku, kdy se to dostane do
neudrzovatelneho stavu vypada. Zatim
> jsem, vedom si tohoto pravidla, spolupracoval
pouze na nekolika projektech
> ktere meli hlavu a patu a byly zvlast zajimave.
Velmi nerad to
> rikam, ale je
> to realita.
Docela by mne to zajimalo: Ktery z teoretickych
pristupu, ktere jsou v soucasne dobe moderni, je
prave ten pravy, abych se za 2-3 roky nedozvedel,
ze program je postaveny na zcela spatnych nebo
zastaralych teoretickych zakladech?
Muzes nam DNES poradit tak, abych za dva roky
nevytahnul tento mail a nerekl, ze Petr Vones
radil spatne?
Prohlasit "Teorie neni nanic, pokud se aplikuje
vcas" a ze
"vetsina aplikaci je zprasenych" v
oboru, jako je vyvoj software, kde se postupy a
pristupy meni tak casto, ze se clovek pomalu ani
nestiha naucit zkratky novych technologii je
takzvana "hrabeci rada". Ohledni se zpatky, co
bylo moderni pred 4 roky. Zkus delat na projektu,
ktery ma dlouhodobe trvani. Pokud budes
chtit "aplikovat teorii vcas", tak to budes
zrejme predelavat kazde dva roky. Nebo spise
kompletne zahazovat a delat stale znova od
zacatku podle toho, co prave ta nova, skvela,
nejlepsi a nejmodernejsi teorie pozaduje.
Pises, ze "ze si malokdo necha poradit ... jsem,
vedom si tohoto pravidla".
Ale neni to nahodou
jinak? Co kdyz to neni tim, za by na
tech "zprasenych" projektech delali zaostali
blbci. Co kdyz je to tim, ze technologie se meni
tak rychle, ze nez ji do velkych projektu
aplikujes, tak uz je zastarala? Co kdyz je to
take otazka nakladu? Jak budes presvedcovat
ekonomickeho namestka, kdyz ti zcela opravnene
rekne:
"Jeste se nevratily naklady na nakup
novych x-licenci Delphi (databaze, CASE
nastroje, ...) a uz mame kupovat nove?"
> Zbytecnou dokumentaci ? Predstav si, ze
pracujes na projektu, kde budes
> dokumentovat kazdou tridu, jeji metodu a vazbu
na ostatni casti
> projektu. Ze
> to neni zbytecne poznas. Nekdy hned, nekdy
pozdeji. Clovek se stale uci a
> zkusenost je v mnoha pripadech neprenosna.
Podle Tvoji odpovedi to vypada, jako bych snad
napsal nebo si myslel, ze dokumentace je
zbytecna.
Ja jsem ale mluvil o dokumentovani zbytecnych
veci. Asi jsem to napsal spatne.
S pozdravem
Bohuslav Svancara, prom. mat.
svancara@softprojekt.cz
Odpovedá: Petr Vones
17. 10. 2002 19:37
From: <boh.svancara@quick.cz>
> Docela by mne to zajimalo: Ktery z teoretickych
> pristupu, ktere jsou v soucasne dobe moderni, je
> prave ten pravy, abych se za 2-3 roky nedozvedel,
> ze program je postaveny na zcela spatnych nebo
> zastaralych teoretickych zakladech?
Vubec jsem nemluvil o tom jestli je neco zastarale nebo ne, ale ze je to z
hlediska navrhu zkratka nesmyslne a neudrzovatelne. To prece vubec nesouvisi
s technologii, spatne navrzenou aplikaci muzes dnes napsat jak v Delphi 7 tak
v Turbo Pascalu 5.5
> Muzes nam DNES poradit tak, abych za dva roky nevytahnul tento mail a
> nerekl, ze Petr Vones radil spatne?
Ne. Uz treba proto, ze vetsina dotazu zde v konferenci je obvkle vytrzena z
kontextu daneho projektu, takze odpoved muze byt sice v ramci tohoto omezeni
spravna, ale pri zarazeni do projektu se to pak muze jevit jinak. Navic nikdo
nejsme neomylny a take vetsinou po case tihneme k urcitym stereotypum v reseni
problemu.
> ktery ma dlouhodobe trvani. Pokud budes
> chtit "aplikovat teorii vcas", tak to budes
> zrejme predelavat kazde dva roky. Nebo spise
> kompletne zahazovat a delat stale znova od
> zacatku podle toho, co prave ta nova, skvela,
> nejlepsi a nejmodernejsi teorie pozaduje.
To prave zalezi na tom, jak moc spatne to v te 'o krok starsi' technologii
udelas. Samozrejme nelze jednu vec udrzovat pri zivote deset let tim, ze se
budes jen snazit, aby se to alespon prelozilo. V urcitem okamziku je dobre se
na vec podivat jinym pohledem a nebat se ji zahodit a od zakladu predelat.
Pokud se budeme bavit o Delphi, tak prvnim takovym okamzikem byl prechod z
16ti bitovych aplikaci na 32 bitove, kde operacni system (Win32) mel konecne
podobu a vlastnosti skutecneho operacniho systemu. Druhou takovou vlnou byl
prechod od souborovych databazi k SQL serverum, vcetne osvojeni si principu
C/S. Dalsim vyraznym posunem ve VCL bylo zavedeni konceptu akci, ktere maji
pomerne velke moznosti a umozni zjednodusit a zprehlednit vyvoj GUI aplikaci.
> blbci. Co kdyz je to tim, ze technologie se meni
> tak rychle, ze nez ji do velkych projektu
> aplikujes, tak uz je zastarala? Co kdyz je to
Zastaralost a nepropracovanost navrhu jsou dve zcela odlisne veci. To prvni
nemusi byt jeste takovy problem dokud to neprekroci urcitou mez, to druhe je
pak prusvih daleko vetsi Plno technologii take zanike driv, nez se je
vubec podari uvest do praxe.
> rekne:
"Jeste se nevratily naklady na nakup
> novych x-licenci Delphi (databaze, CASE
> nastroje, ...) a uz mame kupovat nove?"
O tom je prece dnesni svet masoveho software. Bude ti napriklad Borland dnes
opravovat chybu v Delphi 5 ? Ne, doporuci koupi nove verze, kde je to uz
opravene. Nebo, zakaznik bude (zcela logicky) pozadovat aby aplikace pracovala
korektne pod Windows XP s pouzitim temat. Tuto podporu ma VCL az v Delphi 7,
takze at chces nebo ne, jsi tlacen okolnostmi do nove verze. Netvrdim ze se mi
tato vec libi, ale je to realita.
Vratme se ale k tomu puvodnimu problemu. Ten byl o tom, ze v nekterych castech
aplikace pouzivas vyjimky k oznameni chybne hodnoty zadane uzivatelem, pricemz
pouziti vyjimky ti je vnuceno navrhem VCL, udalosti TField.OnValidate. Reseni
je prece relative snadne, zaved si napriklad vyjimku EUserMessage s vlastnosti
Text, kterou budes vyvolavat z te udalosti a specielne pak osetris v
Application.OnException (presneji receno, v kodu ExceptionDialogu). Pak prece
neni nutne vyjmenovavat vsechny vyjimky indikujici neocekavanou chybu (ty ani
totiz nemuzes vsechny znat), ale naopak obslouzit pouze tuto znamou vyjimku
zobrazenim dialogu s EUserMessage.Text. Samozrejme to znamena mit spolecnou
funkci pro vyvolani teto vyjimky z TField.OnValidate. Predpokladam, ze tvoje
soucasne reseni vypada tak, ze se ve stejne situaci vyvolavaji ruzne vyjimky,
takze nelze pouzit zadnou systematickou obsluhu a proto jsem to oznacil za
spatny navrh.
Petr Vones
Odpovedá: Zbysek Hlinka
18. 10. 2002 10:07
On 17 Oct 2002 at 19:49, Petr Vones wrote:
> Pokud se budeme bavit o Delphi, tak prvnim takovym okamzikem byl
> prechod z 16ti bitovych aplikaci na 32 bitove, kde operacni system
> (Win32) mel konecne podobu a vlastnosti skutecneho operacniho systemu.
> Druhou takovou vlnou byl prechod od souborovych databazi k SQL
> serverum, vcetne osvojeni si principu C/S. Dalsim vyraznym posunem ve
> VCL bylo zavedeni konceptu akci, ktere maji pomerne velke moznosti a
> umozni zjednodusit a zprehlednit vyvoj GUI aplikaci.
Nyni to vypada tak, ze dalsim zlomovym okamzikem bude .NET. Pokud
nekomu dozrava aplikace na totalni prepsani, klonil bych se k navrhu
nezacinat si uz nic s COM, ADO, OLE DB a poseckat na .NET, a mezitm
si o tom neco precist.
S pozdravem
Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282
Odpovedá: Petr Vones
18. 10. 2002 14:32
From: "Zbysek Hlinka" <hlinka@hlinka.cz>
> Nyni to vypada tak, ze dalsim zlomovym okamzikem bude .NET. Pokud
On uz je, bohuzel Borland ma zatim zda se s .NET verzi svych nastroju vcelku
zpozdeni.
Petr Vones